Типовая задача с внедрений. Из системы А следует загрузить данные в пакетном режиме в систему Б. Сначала прогрузить многомиллионный или миллиардный исторический объем, а затем отрегулировать регулярные инкрементальные загрузки.
Расскажу, что необходимо учитывать при проектировании интеграции, и почему нельзя ограничиваться только маппированием.
Понимание масштаба бедствия при проектировании интеграции позволит сберечь нервы всем участникам процесса и избежать риска срыва сроков.
Пример из жизни. Ожидаем, что в систему Б будет загружено 100 млн данных к дате Х, а по факту загрузили в 10 раз меньше. После нескольких перегрузок, сорвав сроки, данные все-таки загрузили. Но потом еще 3 года отправляли корректировочные инкременты, когда выяснялось, что то про обработку справочников забыли, то фильтр отбора данных потеряли, то что-то еще случалось.
Круглый стол - 40 минут.
Все знают стандартную мотивацию: морковка сзади и морковка спереди, т.е. мотивация рублем (з-п, премии) и наказанием (шртафы, ор и пр.). Но зачастую в ИТ это не работает или работает слабо.
На круглом столе мы поговрим о возможностях применения нематериальной мотивации аналитиков. Нужна ли нематериальная мотивация? Что это такое? Когда работает, когда не работает. Какие методы лучше применять?
Об этом и многом другом поговорят: Александр Байкин, Ирина Баржак, Ирина Гертовская, Алмаз Габиддулин, Надежда Смирнова, Татьяна Долгина.
Аналитикам говорят “пишите НФТ”, и они их “пишут”. Разработчики разрабатывают систему и внезапно оказывается, что система не удовлетворяет этим “НФТ” (если “НФТ” вообще возможно проверить). Проблема кроется в пропущенном этапе проектирования - для удовлетворения “НФТ” недостаточно их заявить, нужно придумать “как это обеспечить” - создать подходящую модель системы, сталкиваясь с задачами поиска компромисса между потерями от необеспечения и расходами на обеспечение. Более того, детальное понимание потребностей качества мы можем зафиксировать только после проработки детальной модели их обеспечения. При этом, при проработке может оказаться так, что придется менять уже созданные функциональные модели системы или прорабатывать дополнительные модели системы.
В докладе мы на примере разберем как это делать для аспекта отказоустойчивости, производительности и быстродействия.